兩條分支成功合併，並不代表程式碼是OK的，譬如，商業邏輯的錯誤。
通常合併之後，都還會經過測試。

分階段合併

延續Git-fast-forward快轉模式。
先將feature分支砍掉，再重新建立。
並且新增2個檔案。

feature分支領先master分支兩個版本。

在master分支合併feature分支，預設會使用fast-forward。
上一篇也提過，fast-forward不會有commit。若使用分支合併，就會產生合併commit。
那能否在使用分支合併當中，先不要commit，等我們確認程式碼無誤，再進行commit呢？

答案是可以的。
使用--no-commit，這樣一來，就不會先commit，而是讓我們確認完畢，再自行手動commit。

訊息表示：合併正常進行，但在我們要求commit之前停止了。
換句話說，我們要自行commit，這個合併才會完成。
這時的分支狀態(master|MERGING)，顯示正在合併中。

即使合併未完成，資料夾目錄卻已經變更了。

查看git status。

訊息表示：沒有衝突，但仍然在合併中的狀態。
(use "git commit" to conclude merge)，訊息提示，使用git commit來結束這次合併。

我們在這段期間，可以對資料做任何異動，假設再增加一個檔案。

查看git status。

新增成功。

執行git commit完成合併。
我們可以自行增加commit訊息：add 3.txt。

OK，成功合併。

線圖。

以上就是，將合併拆成兩階段來執行的過程。

壓縮合併

回復剛剛的合併。指令 git reset --hard ORIG_HEAD
在master分支新增檔案，執行commit。

這時，master分支與feature分支，都有各自的commit，所以合併不會使用fast-forward模式。
使用fast-forward模式，有個明確的規範，即將合併的版本，必須是自己的之後版本。

壓縮合併指令：--squash

訊息跟剛剛差不多。
Squash commit -- not updating HEAD：表示因為使用壓縮合併，git不會更新HEAD，這部分我們要自行更新。

查看git status

合併完成，但還沒有commit。

資料夾目錄卻已經變更

所以，壓縮合併到底是什麼？
壓縮合併的功能，是將feature分支所有的commit(2個)全部壓縮至master分支的下一個commit。

執行git commit，訊息會說明，這次的合併，會壓縮以下的commit，正是feature分支的commit。

壓縮合併完成後，訊息會說明已完成下面commit的壓縮。

查看線圖，會發現，feature分支像斷掉一樣，並沒有延伸至master分支最新的commit。

這是因為剛剛說過的，壓縮合併的結果，會在master分支再建立一個新的commit，包含所有的feature分支commit。
也可以這樣說，git會壓縮feature分支的所有commit，並加入master分支的下一個commit。

git log訊息很清楚的說明，這次的commit包含了哪些壓縮的commit。

使用壓縮合併的情境

假設我們只是在分支做個小測試，並不需要特地保留合併分支的線圖。
這時就可以使用壓縮合併。

刪除分支

刪除後的線圖

會發現，feature分支整個消失了，但它的commit結果還是會在master分支之中。

使用限制

最後一點要說的是，--no-ff與--squash指令，是不允許一起使用的。

因為，--no-ff會強迫有分岔的線圖；但--squash不會產生分岔的線圖，
他們是衝突的，所以這樣的指令當然會失敗。

本文為觀看網路教學的學習筆記。